За последние пару месяцев на сайте проекта VMware Labs вышло несколько обновлений утилиты vSphere Diagnostic Tool. Напомним, что это средство представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi. О первой версии vSphere Diagnostic Tool мы писали вот тут.

Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.

Давайте посмотрим, что нового появилось в vSphere Diagnostic Tool (сейчас актуальная версия 1.1.4) с момента ее последнего релиза:

• Исправлены проблемы со спецсимволами в паролях
• Тесты имеют таймаут 10 секунд, а ключ -f используется для пропуска таймаутов
• Название проверки выводится еще до ее запуска
• Проверка VC Disk Space Check теперь игнорирует раздел proc
• Проверка VC Info Check теперь имеет приятный вывод и возможность вывода во внешний канал PSC
• Улучшены проверки VC Core Check
• Исправлено множество ошибок, связанных с обработкой паролей и сертификатов

Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).

Скачать утилиту vSphere Diagnostic Tool можно по этой ссылке.

Многие компании сталкиваются сегодня с необходимостью переезжать на другую платформу виртуализации из-за сложностей, связанных с поддержкой зарубежных решений, а также ростом курсов валют. Сегодня мы расскажем об одной из альтернатив, которую предлагает российскому бизнесу компания HOSTVM, и рассмотрим алгоритм миграции на платформу. Сама по себе платформа HOSTVM представляет собой российскую версию гипервизора, построенного на базе открытого исходного кода KVM...

Многие администраторы VMware vSphere знают, что есть такой портал VMware Marketplace, где доступно более 2300 партнерских решений и продуктов для дополнения виртуальной инфраструктуры, онпремизной и облачной.

Портал VMware Marketplace позволяет сотрудникам DevOps, IT-администраторам, администраторам ИБ и прочим ИТ-специалистам получить доступ к огромному количеству решений, разбитых на категории, такие как Identity, Networking и Security, которые можно попробовать перед покупкой. Они поставляются в различных форм-факторах - виртуальные модули OVA, готовые к развертыванию контейнеры, а также менеджмент паки.

Решения от независимых поставщиков проходят программу валидации и сертификации VMware Ready и Partner Ready, для которых отображаются соответствующие бейджи на их страницах в маркетплейсе. ISV-партнеры, разрабатывающие продукты для маркетплейса, должны быть в составе экосистемы разработчиков Technology Alliance Program (TAP) компании VMware.

Только в феврале этого года на маркетплейс было добавлено 39 новых решений в различных категориях (кликайте на заголовок категории, чтобы увидеть все решения, доступные в ней):

• Domino Data Science Seat

• 3DEXPERIENCE platform
• Helix International

• Kodak Prinergy Workflow

• YugabyteDB Anywhere – Distributed SQL Database

• GitLab Ultimate

• 10ZiG 4648q Zero Client
• 10ZiG 7748qv – Linux (x64)
• 10ZiG 6010q – Windows IoT Thin Client
• 10ZiG 6110 – Windows 10 IoT Thin Client
• ImageScan Pro 820ix
• LG 24CN650 Thin Client
• LG CL600 Thin Client
• Micron 7400 NVMe SSD for VMware vSAN

• Beyond Identity Secure Work

• Virtual PLC for Industrial Automation

• ETERNUS vRealize Orchestrator Plug-in
• ITmanager.net – The RMM Mobile App
• Interlink Software AIOps Platform
• Login Enterprise
• Sightline EDM for IT Systems
• Stratodesk NoTouch Center VA – VDI Endpoint Management
• Veryx vTAP
• vRealize Operations Management Pack for Storage Devices 8.4.1
• vRealize Operations Management Pack for Horizon 1.2.2
• vRealize Operations Tenant App for VMware Cloud Director 8.6.1
• vRealize Operations Management Pack for VMware Cloud Director 8.6.1
• vRealize Operations Management Pack for SNMP 3.2.1
• VMware vRealize Orchestrator Plug-in for vRealize Automation 8.4.2+
• vRealize Orchestrator plug-in for Site Recovery Manager
• vRealize Orchestrator plug-in for vSphere Replication

• Arrcus ACE Platform

• vArmour Relationship Cloud
• VMWare Carbon Black Cloud Connector For Malwation AIMA Platform

• Lightbits Cloud Data Platform
• ObjectScale Software-Defined Object Storage
• SK Hynix PE8000 Enterprise NVMe SSDs
• SSSTC Solid State Drive
• virvcache

В общем, VMware Marketplace - это отличное место для поиска нужных вам дополнений для виртуальной инфраструктуры, особенно если вы используете продукты специфических вендоров или нуждаетесь в дополнительных средствах управления и мониторинга различного оборудования или ПО.

На днях компания VMware обновила главный документ о производительности своей флагманской платформы виртуализации - Performance Best Practices for VMware vSphere 7.0, Update 3. Напомним, что с пакетом обновлений Update 3 долгое время были проблемы (в том числе с производительностью), но сейчас доступна стабильная версия этого обновления. Осенью прошлого года мы также писали об этом документе для версии Update 2.

Традиционно документ разбит на 4 больших блока, касающихся оборудования, самой платформы vSphere и серверов ESXi, виртуальных машин, их гостевых систем и средств управления виртуальной инфраструктурой:

• Hardware for Use with VMware vSphere
• ESXi and Virtual Machines
• Guest Operating Systems
• Virtual Infrastructure Management

Подразделы этих глав содержат очень много конкретных пунктов про различные аспекты оптимизации виртуальных датацентров и объектов, работающих в их рамках.

Документ очень полезный, состоит из почти ста страниц и дает просто огромное количество полезной информации для администраторов, одной из главных задач которых является поддержание требуемого уровня производительности виртуальной среды.

Скачать Performance Best Practices for VMware vSphere 7.0, Update 3 можно по этой ссылке.

Компания Principled Technologies выпустила интересное сравнение производительности в контексте плотности размещения виртуальных машин на сервере (VM Density), которое показывает превосходство гипервизора VMware vSphere 7 Update 2 над открытой архитектурой Red Hat OpenShift версии 4.9.

Для тестирования использовались виртуальные машины с полезной нагрузкой SQL Server. С точки зрения оборудования использовался кластер из 5 одинаковых серверов HPE ProLiant DL380 Gen 10, где были размещены ВМ, также для OpenShift дополнительно использовались еще 3 хоста как управляющие узлы.

Первый результат теста - это максимальное число активных виртуальных машин на один узел, которые можно было разместить при обеспечении определенного уровня производительности SQL Server. Тут результат 14-30 в пользу платформы VMware vSphere 7 Update 2:

Также создавали простаивающие виртуальные машины и смотрели, какое их максимальное количество можно разместить на одном хосте, тут тоже vSphere далеко впереди:

В исследовании отдельно подчеркивается, что VMware vSphere имеет также следующие преимущества:

• Механизм обеспечения высокой доступности VMware HA работает более эффективно и проще настраивается
• Рутинные задачи (Day-2) на платформе VMware vSphere выполнять удобнее и быстрее
• Для хостов ESXi можно делать апгрейд хостов без их перезагрузки

Ну и сообщается, что решение vSphere with Tanzu позволяет исполнять нагрузки в контейнерах Kubernetes, которые дополняют серверную инфраструктуру. Больше подробностей вы можете узнать из исследования "VMware vSphere 7 Update 2 offered greater VM density and increased availability compared to OpenShift Virtualization on Red Hat OpenShift 4.9".

Продолжаем рассказывать о продукте NAKIVO Backup & Replication, предназначенном, в основном, для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V. Но сегодня мы расскажем еще об одной полезной функции этого продукта - бэкап физических серверов, не состоящих в виртуальной среде.

Недавно мы писали о выходе новой версии пакета продуктов VMware Cloud Foundation 4.4, предназначенного для создания виртуального датацентра организации. Напомним, что он включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

Напомним, что одной из новых возможностей VCF 4.4 стало то, что теперь сервис SSH отключен на всех хостах ESXi по умолчанию - это новая конфигурация, которая применяется в соответствии с рекомендациями по безопасности.

Если по какой-то причине на одном или нескольких хостах в рамках доменов рабочей нагрузки (workload domains) вам нужно использовать SSH, то вот как можно это сделать.

Чтобы включить SSH на всех доменах и хостах ESXi вашей инфраструктуры, нужно выполнить следующую консольную команду SDDC Manager как root:

/opt/vmware/sddc-support/sos --enable-ssh-esxi --domain-name ALL

Если нужно включить SSH на одном из доменов, то делается это так:

/opt/vmware/sddc-support/sos --enable-ssh-esxi --domain-name domain1

Если же вам необходимо включить SSH на отдельном хосте ESXi, то нужно выполнить следующие действия:

• Заходим через веб-браузер на ESXi в его VMware Host Client
• Нажимаем Manage в панели навигации и переходим на вкладку Services
• Выбираем службу TSM-SSH и нажимаем Start

Как знают администраторы VMware vSphere, сервер управления виртуальной инфраструктурой vCenter умеет исполнять задачи, создаваемые различными пользователями, в параллельном режиме в целях ускорения работы. Их может быть несколько сотен, а число одновременных сессий от пользователей в теории может достигать двух тысяч.

Не так давно компания VMware выпустила интересное видео "Extreme Performance Series: vCenter Concurrency", где рассказывается о различных аспектах работы этого механизма:

Также вам могут оказаться полезными следующие статьи о vCenter и его механизме параллельно исполняемых задач, материал из которых релевантен обсуждаемому в видео выше:

• Лимиты vCenter для задач, исполняемых одновременно
• Лучшие практики и производительность тэгов vSphere 7.0 U1
• Использование vCenter для развертывания и мониторинга мультиоблачных задач
• Сессия vCenter Performance Deep Dive с VMworld 2020

Компания VMware недавно сделала доступным для загрузки обновление пакета продуктов VMware Cloud Foundation (VCF) версии 4.4, предназначенного для создания онпремизного виртуального датацентра. Напомним, что он включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

Давайте посмотрим, что нового в VCF 4.4: 

• Гибкие апгрейды vRealize Suite - теперь апгрейд продуктов, входящих в состав vRealize Suite, полностью управляется со стороны vRealize Suite Lifecycle Manager. Как только новая версия какого-то продукта становится доступна - ее можно обновить с помощью Lifecycle Manager, при этом происходит проверка совместимости версий продуктов в составе vRealize Suite. Поэтому теперь в составе Bill of Materials (BOM) не приводятся отдельные версии решений vRealize Automation, vRealize Operations, vRealize Log Insight и Workspace ONE Access, которые будут обновляться через Lifecycle Manager.
• Улучшения в пречеках апгрейда - теперь проверяется емкость файловой системы, разрешения для файлов и пароли. Это обеспечивает более плавный процесс апгрейда.
• Сервис SSH отключен на хостах ESXi по умолчанию - это новая конфигурация, которая применяется в соответствии с рекомендациями по безопасности.
• Возможность логировать пользовательскую активность - теперь все эти логи сохраняют вызовы VMware Cloud Foundation API вместе с контекстом пользователя. Также логируются логины и логауты в консоль SDDC Manager.
• Поддержка 2-узловых кластеров vSphere при использовании NFS, VMFS on FC или vVols в качестве основного хранилища кластера (эта возможность не применяется при использовании vSAN, а также при использовании бейзлайнов Lifecycle Manager для обновлений).
• Обновления безопасности:
  • Заплатки уязвимости Apache Log4j Remote Code Execution (исправления для уязвимостей CVE-2021-44228 и CVE-2021-45046, подробнее описано в VMSA-2021-0028).
  • Исправления безопасности для Apache HTTP Server (а именно CVE-2021-40438, подробнее описано в VMSA-2021-0020).
• Улучшения эффективности SDDC Manager в плане использования процессора и памяти. Также теперь инвентарь в консоли работает лучше и объекты (хосты ESXi, workload domains и другие) открываются быстрее.
• Multi-Instance Management Dashboard недоступна больше в интерфейсе SDDC Manager.
• BOM updates - в состав пакета были добавлены обновленные версии соответствующих продуктов (см. ниже).

Собственно, вот какие продукты VMware и их версии теперь входят в состав VMware Cloud Foundation 4.4:

Также пользователи прошлой ветки VMware Cloud Foundation 3.х получили обновление 3.11, вот что там нового:

• Заплатки уязвимости Apache Log4j Remote Code Execution (исправления для уязвимостей CVE-2021-44228 и CVE-2021-45046, подробнее описано в VMSA-2021-0028).
• Исправления безопасности для Apache HTTP Server (а именно CVE-2021-40438, подробнее описано в VMSA-2021-0020).
• Улучшения в пречеках апгрейда - теперь проверяется емкость файловой системы, разрешения для файлов и пароли.
• Утилита апгрейда skip-level upgrade CLI tool, позволяющая обновиться на VCF 3.11 напрямую, теперь получила несколько улучшений в плане предпроверок, проверок безопасности и юзабилити.
• Новые максимумы - теперь VCF 3.11 поддерживает до 1000 хостов ESXi на один SDDC Manager.
• Обновления Bill of Materials - теперь в состав пакета входят продукты ESXi 6.7 EP23, vCenter Server 6.7 U3q, NSX-v 6.4.12 и NSX-T 3.0.3.1, vRealize Suite Lifecycle Manager 2.1 Patch3 и VMware Horizon 7.10.3.

Подробнее о VMware Cloud Foundation можно узнать вот тут.

Год назад мы писали о том, что VMware обновила свой основной документ об обеспечении безопасности виртуальной среды VMware vSphere 7 Security Configuration Guide, а также рассказывали о главных настройках и конфигурациях, описанных в нем.

Не все знают, что у VMware есть руководства по безопасности не только самой платформы, но и некоторых других продуктов, которые можно найти по этой ссылке.

Например, недавно обновился документ NSX-T 3.2 Security Configuration Guide, рассказывающий об обеспечении безопасной конфигурации решения для виртуализации и агрегации сетей NSX-T 3.2, о новых возможностях которого мы писали вот тут.

Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware NSX-T изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.

Как обычно, руководство состоит из двух файлов:

• XLSX-таблица со всеми конфигурациями и объяснениями по их настройке
• PDF-файл с описанием лучших практик по созданию безопасной конфигурации (документ Securing VMware NSX-T Data Center)

Основная таблица руководства разбита на 5 вкладок:

• Doc. Info - описание колонок таблиц (см. ниже).
• Management Plane - рекомендации и конфигурации для управляющих компонентов.
• Data Plane - настройки, касающиеся работы с трафиком.
• Appendix - ссылка на документ о портах и соединениях для VMware NSX-T.
• Change Log - история изменений документа.

Ну а вот как выглядят основные поля приведенных в таблице конфигураций:

• ID - идентификационное имя рекомендации.
• Component - это продукт VMware или другой компонент виртуальной среды (например, гипервизор KVM).
• Subcomponent - это логическая группировка рекомендаций и конфигураций по категориям.
• Title - лаконичная формулировка сути этой рекомендации.
• Vulnerability Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются безопасности в связи с изменением настройки.
• Assessment Procedure - пошаговое описание процедур, которые нужно выполнить, чтобы получить желаемую конфигурацию.
• Word of Caution - это информация о потенциальном негативном эффекте от изменения данной настройки.
• Desired Value - рекомендуемое значение, часто оно является значением по умолчанию.
• Is the setting default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• API - это ссылка на соответствующий NSX-T REST API.
• Reference - отсылка к документации или другим объектам, которые более детально описывают данную конфигурацию.

Скачать VMware NSX-T 3.2 Security Configuration Guide можно по этой ссылке.

Почти два года назад мы писали об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Сегодня мы расскажем об управлении сертификатами VMware vSphere с помощью PowerCLI на основе материалов вот этой статьи в блоге VMware.

Все необходимые функции для работы с API по управлению сертификатами были добавлены в PowerCLI версии 12.4 в конце прошлого года, и теперь можно полноценно управлять ими с помощью сценариев.

Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:

• Add-VITrustedCertificate
• Get-VIMachineCertificate
• Get-VITrustedCertificate
• New-VIMachineCertificateSigningRequest
• Remove-VITrustedCertificate
• Set-VIMachineCertificate

Итак, давайте посмотрим, как они работают:

1. Управление доверенным хранилищем сертификатов

Для работы с Trusted Certificate Store можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:

#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates

Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }

Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:

#Read the certificate or certificate chain from a .pem file

$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw



#Add it to the trusted certificate stores of the vCenter and the ESXi servers

Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain

Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:

Get-VITrustedCertificate -VCenterOnly | `

Where-Object { $_.NotValidAfter -lt (Get-Date) } | `

Remove-VITrustedCertificate

2. Управление SSL-сертификатами компьютеров на сервере vCenter Server

Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).

Сначала с помощью этого командлета проверяем текущий сертификат машины vCenter:

Get-VIMachineCertificate -VCenterOnly

После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:

$csrParams = @{

Country="US"

Email="jdoe@vmware.com"

Locality="San Francisco"

Organization="My Company"

OrganizationUnit="PowerCLI"

StateOrProvince="California"

}

$csr = New-VIMachineCertificateSigningRequest @csrParams


$csr.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\vc.csr.pem" -Force

После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:

$vcCert = Get-Content "C:\Users\jdoe\Downloads\vc.cert.jdoe.pem" -Raw

Set-VIMachineCertificate -PemCertificate $vcCert

Перед установкой SSL-сертификата машины мы должны убедиться, что корневой сертификат нашего CA добавлен в хранилище сертификатов vCenter Server. Помните, что замена сертификата вызовет перезагрузку vCenter.

3. Управление SSL-сертификатами машин для серверов ESXi

Если мы хотим управлять сертификатами полностью самостоятельно, нужно также заменить и сертификаты хостов ESXi. Рабочий процесс в этом случае выглядит несколько сложнее. Сначала нужно изменить настройку режима управления сертификатами хостов ESXi на custom на сервере vCenter и перезагрузить его.

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'

$certModeSetting = Get-AdvancedSetting "vpxd.certmgmt.mode" -Entity $vCenterConnection

Set-AdvancedSetting $certModeSetting -Value "custom"

После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.

$esxRequest = New-VIMachineCertificateSigningRequest `

-VMHost $vmhost `

-Country "US" `

-Locality "San Francisco" `

-Organization "My Company" `

-OrganizationUnit "PowerCLI" `

-StateOrProvince "California" `

-CommonName <ESXi host's FQDN> or <ESXi host's IP address>


$esxRequest.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\esx.csr.pem" -Force

Теперь, когда мы получим сертификат от центра сертификации, нужно выполнить 3 операции:

1. Выводим хост в режим обслуживания (maintenance mode) и удаляем его из vCenter:

$vmhost = Get-VMHost 'MyESXiHost' `

Set-VMHost -VMHost $vmhost -State Maintenance

Remove-VMHost $vmhost

2. Соединяемся с хостом ESXi напрямую, устанавливаем там сертификат и перезагружаем хост:

$esxConnection = Connect-VIServer $vmhost.Name `

-User 'My User' `

-Password 'My Password' `

-Force


$esxCertificatePem = Get-Content "C:\Users\jdoe\downloads\myesxcert.pem" -Raw

$targetEsxHost = Get-VMHost $vmhost.Name

Set-VIMachineCertificate -PemCertificate $esxCertificatePem -VMHost $targetEsxHost | Out-Null



Restart-VMHost $targetEsxHost



Disconnect-VIServer $esxConnection

Так же, как и для vCenter, перед установкой сертификата машины нужно убедиться, что корневой сертификат нашего центра сертификации добавлен в доверенное хранилище сертификатов на хосте ESXi и других серверах, с которыми он взаимодействует, то есть остальные хосты ESXi и vCenter.

Снова добавляем наш хост ESXi в vCenter:

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'


$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `

-Location (Get-Datacenter "My Datacenter")`

-User "My User" `

-Password "My Password"


$vmhost = Set-VMHost -VMHost $vmhost -State Connected

Ну и остальные идеи вы можете почерпнуть в документе PowerCLI User’s Guide.

Мы уже давно не писали об обновлении утилиты RVTools, предназначенной для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах. В начале февраля вышло обновление этого средства - RVTools 4.3.1.

Давайте посмотрим, что там нового:

• RVTools теперь использует VMware vSphere Management SDK 7.0U3.
• Новая вкладка vSource, на которой отображается информация о сервере, где исполняется веб-сервис SDK, который используется для сбора данных (это сервер vCenter или хост ESXi).
• Новая колонка Host UUID на вкладке vHost.
• Новые чекбоксы в разделе Health, которые включают/отключают сообщения о безопасности и производительности.
• Раньше колонка UUID заполнялась значениями SMBIOS UUID, которые не уникальны. Теперь там отображается уникальный 128-битный UUID.
• Улучшение производительности при обработке данных.
• На вкладке vHealth появились советы по улучшению производительности ввода-вывода и памяти.
• Исправления ошибок.

Также приведем основные улучшения RVTools с момента выпуска четвертой версии:

• Новая вкладка vUSB, отображающая хосты с присоединенными USB-устройствами.
• Новая вкладка vFileInfo с информацией обо всех файлах на датасторах vSphere (полная информация включается чекбоксом Get fileinfo detail information").
• Log4net обновлен до версии 2.0.12 (защита от уязвимости CVE-2018-1285).
• Отображение информации о том, является ли объект плейсхолдером резервной инфраструктуры VMware SRM.
• Новая колонка Virtual machine tags на вкладках vInfo, vCPU, vMemory, vDisk, vPartition, vCD, vFloppy, vNetwork, vSnapshot, vTools.
• Новая колонка вкладки vInfo: min Required EVC Mode Key.
• Новая колонка вкладки vMemory: Memory Reservation Locked To Max.
• Новые колонки вкладки vRP: Resource Pool path, Resource Pool tags, число ВМ в пуле ресурсов и object ID.
• Новые колонки вкладки vCluster: Cluster tags, custom attributes и object ID.
• Новые колонки вкладки vHost: число ВМ в пуле ресурсов, vSAN Fault Domain Name, Host tags, in Maintenance Mode и in Quarantine Mode.
• Новые колонки вкладки dvSwitch: Distributed VirtualSwitch tags, custom attributes и object ID.
• Новые колонки вкладки dvPort: Distributed VirtualSwitch Port Group tags и object ID.
• Новые колонки вкладки vDatastore: число ВМ в пуле ресурсов, Datastore tags, custom attributes и object ID.
• Новые колонки вкладки vNetwork: ipv4 и ipv6, NIC label, "Internal Sort Column".
• Новые колонки вкладки vDisk: Disk key, disk path, "Internal Sort Column".
• Новые колонки вкладки vPartition: "Internal Sort Column", Disk key.
• Новый чекбокс в настройках "Exclude tags" и параметр CLI -ExcludeTags.
• Объем отображается не в MB, а в MiB.
• Предупреждение о том, что данные собраны не со всех ВМ.

Скачать RVTools 4.3.1 можно по этой ссылке.

В начале февраля компания VMware сообщила, что убрала из списка доступных загрузок дистрибутив своего средства vCenter Converter, которое предназначено для перенесения физических и виртуальных машин с различных платформ в среду VMware vSphere.

Сделано это было из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивается - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого. Поддержка этого продукта закончилась в декабре 2019, а последний раз о нем мы упоминали вот тут. Выглядел он тогда так:

Напомним, что для корпоративной инфраструктуры есть средство VMware HCX Enterprise, которое предназначено для переноса виртуальных машин из локального датацентра в облачную инфраструктуру сервис-провайдеров VCPP или публичных облаков, но вот для P2V-миграции внутри датацентра решения от VMware больше нет.

Между тем, VMware заявляет, что работа над новым VMware vCenter Converter ведется, и обязательно будет выпущена его полностью переработанная версия. Сроков пока не называют, поэтому, скорее всего, случится это не раньше конференции VMworld 2022, которая пройдет осенью.

Мы уже писали о том, что на сервере VMware ESXi может возникать ошибка "No space left on device" при выполнении различных операций. Тогда мы объясняли, что такая ситуация может произойти из-за исчерпания числа свободных объектов inodes.

Причина такого поведения может заключаться не только в отсутствии свободных нод. Для начала надо проверить, что проблема действительно не в них. Делается это с помощью команды:

stat -f /

Либо можно использовать также команду df -i.

Если все в порядке с айнодами, то проблема может заключаться в так называемых "small file blocks" (SFB) и "large file blocks" (LFB), которые на VMFS создаются под нужды файловой системы для разных типов файлов. Суть самой проблемы в том, что иногда SFB кончаются, и VMFS запускает механизм конвертации LFB в SFB, но получившиеся SFB не становятся доступными сразу. Подробнее об этой механике рассказано в KB 87482.

Решением этой проблемы является только апгрейд вашей инфраструктуры на VMware vSphere ESXi 7.0 Update 3c.

Компания VMware в конце января объявила о том, что ее сервис Skyline доступен через партнерскую сеть облачных сервис-провайдеров (Cloud Providers, они же участники программы VCPP), которые предоставляют свои услуги, используя платформу Cloud Partner Navigator (CPN). Напомним, что это решение предназначено для проактивного получения рекомендаций по технической поддержке продуктов линейки VMware vSphere, включая vSAN. В частности, с помощью VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут делать заключения о правильности работы виртуальной инфраструктуры и вырабатывать основные рекомендации по ее улучшению.

С помощью Skyline Advisor пользователи могут получать проактивную аналитику для своей виртуальной инфраструктуры в целях идентификации текущих и будущих проблем. Он поддерживает не только продукты vSphere, vSAN, NSX, vROps и Horizon, но и среды Cloud Foundation и Dell EMC VxRail.

Все партенры, имеющие доступ к VMware Partner Connect с действующим соглашением VMware Cloud Provider Program agreement, могут получить доступ к поддержке уровня Production. А начиная с 27 января, у них уже есть доступ к сервисам VMware Skyline.

Для сервис-провайдеров тут будет 2 больших плюса:

• Получение инструмента, который позволяет обозначать проблемы пользователей еще до их появления и проактивно действовать в этом направлении.
• Быстро и удобно взаимодействовать с поддержкой VMware через единый портал для ускорения решения проблем пользователей.

На данный момент сервисы Skyline доступны для следующих продуктов:

• VMware vSphere
• VMware NSX
• VMware vSAN
• VMware vRealize Operations
• VMware vRealize Automation
• VMware Cloud Foundation.

Также сервис распознает Skyline инфраструктуру VxRail и инсталляции типа VMware Validated Design.

Если вы являетесь сервис-провайдером VCPP и уже имеете доступ к Cloud Partner Navigator, то сервис доступен в разделе "Services Available for Provisioning".

Это статьей мы начинаем цикл публикаций и продукте NAKIVO Backup & Replication в контексте отдельных его функций. Напомним, что он предназначен для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V. Вводную статью об основных возможностях этого решения вы можете прочитать вот тут, а сегодня мы подробно расскажем о его механизмах по резервному копированию данных сервисов Microsoft Office 365.

Как многие из вас знают, в ноябре прошлого года компания VMware отозвала обновление платформы vSphere 7 Update 3 из-за критических ошибок. Это были проблемы с выпадением в PSOD, трудности при апгрейде с прошлых версий, неполадки в плане стабильности vSphere HA и другое.

В конце декабря мы напомнили о том, что проблема существует уже месяц, а VMware все никак не может решить ее. Основная информация о возникшей ситуации с последним пакетом обновлений публиковалась в KB 86398. Там же можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Теперь VMware объявила о выпуске окончательной версии VMware vSphere 7 Update 3c, где все должно работать как надо (однако бежать обновляться прямо сейчас мы бы не рекомендовали:)

Также сообщается, что в новом релизе решены все проблемы с безопасностью, касающиеся уязвимости Log4j, которая затронула большое количество систем. Эта уязвимость позволяла злоумышленнику, который имел доступ к отсылке логов (самих сообщений или к настройке их параметров), исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена.

Наконец-то были обновлены основные компоненты продукта, ESXi и vCenter, а также опубликован список известных проблем и их обхода:

• vSphere ESXi 7 Update 3c Release Notes
• vCenter Server 7 Update 3c Release Notes
• vSphere 7 Update 3c – List of Known Issues and Workarounds

О новых возможностях основного vSphere 7 Update 3 вы можете почитать у нас тут, их список не изменился. Скачать все компоненты платформы, включая ESXi 7 Update 3c и vCenter Server 7 Update 3c, вы можете по этой ссылке.

Недавно VMware и издательство O'Reilly выпустили бесплатную для всех электронную книгу "Production Kubernetes - Building Successful Application Platforms", которая рассказывает о применении линейки решений VMware Tanzu для контейнерной виртуализации приложений в рамках производственных кластеров Kubernetes. Написана она авторами Josh Rosso, Rich Lander, Alexander Brand и John Harris.

В Enteprise-инфраструктуре перед администраторами контейнеров и серверов виртуализации встают следующие задачи:

• Удовлетворение все растущего спроса разработчиков на размещение контейнеров приложений в кластерах.
• Уход от механизма тикетов на выполнение задач DevOps путем предоставления разработчикам средств самообслуживания и API-механизмов для решения собственных задач.
• Предотвращение ситуации, когда все будет завязано на одного вендора (например, только на его API).
• Соответствие регуляторным требованиям, которые часто требуют размещения приложений и данных только в онпремизной инфраструктуре.
• Поддержка железа для кластеров Kubernetes, а также виртуального датацентра на базе VMware vSphere.

Все эти важные аспекты рассматриваются в данной книге. Полезна она будет как администраторам в целях исполнения своих прямых обязанностей, так и разработчикам, которые хотят расширить кругозор и составить представление о современных подходах к интеграции технологий контейнеризации приложений и серверной виртуализации.

Скачать книгу "Production Kubernetes - Building Successful Application Platforms" можно бесплатно по этой ссылке.

Некоторые из вас, вероятно, знают такой сайт virten.net, где в свое время публиковалось много интересных технических статей об инфраструктуре VMware. Автор этого ресурса делает много интересных вещей, например, средство PowerShell OVF Helper.

OVF Helper - это репозиторий шаблонов для развертывания ВМ из виртуальных модулей (Virtual Appliances) в формате OVF, которые основаны на рабочем процессе развертывания в мастере создания машин vSphere Client. Через OVF Helper вы таким же образом соединяетесь с vCenter Server, заполняете нужные переменные и выполняете сценарий развертывания. Это точно так же просто, как и при использовании vSphere Client, но плюс в том, что вы можете использовать этот сценарий повторно, не проходя вручную шаги мастера клиента vSphere.

Также настроенные параметры в скрипте будут вам отличным напоминанием о том, какую конфигурацию вы использовали для виртуальных модулей.

На данный момент доступны сценарии для следующих продуктов и их версий:

• VMware NSX-T 3.2 | 3.1 | 3.0 | 2.5 | 2.4
• VMware NSX Advanced Load Balancer
• VMware NSX for vSphere 6.x
• VMware Cloud Director 10 | 10.2 | 10.3
• VMware vRealize Operations Manager 8.1
• VMware vRealize Orchestrator 8.1
• VMware vSphere Integrated Containers
• VMware ESXi Virtual Appliance
• VMware Photon OS 3.0 (cloud-init)
• VMware Event Broker Appliance 0.7

Также на странице PowerShell OVF Helper размещены ссылки на OVA-модули, которые рекомендуется использовать совместно с соответствующей версией сценария.

Кстати, обратите внимание на раздел Tools на сайте автора - там много чего интересного:

Компания VMware объявила о выпуске новой версии Photon OS 4.0 rev 2. Напомним, что четвертая версия этой ОС, на базе которой построены виртуальные модули (Virtual Appliances) VMware, вышла в марте прошлого года.

Давайте посмотрим, что нового появилось в этом обновлении:

• Поддержка OpenSSL 3.0 - теперь этот протокол используется по умолчанию
• Новая утилита pmd-nextgen (photon management daemon), которая дает следующие возможности:
  • Удаленное управление системой с поддержкой мобильных устройств
  • Управление сервисами systemd и другими аспектами Photon OS через REST API
  • Использование REST API для конфигураций в реальном времени и тюнинга производительности, а также мониторинга состояния Linux-систем
• Доработки движка реального времени:
  • Улучшения при работе с низкими задержками (low-latency), а также уменьшение джиттера (OS jitter)
  • Повышение стабильности работы и улучшения средств отладки
• Прочие улучшения:
  • Доработки и багофиксы в tdnf
  • Поддержка GNU tarfs для ядра Linux-esx
  • Поддержка eBPF для ядра Linux
  • Улучшения установщика, такие как поддержка устройства Secondary Kickstart и пользовательских настроек монтирования устройств
• Обновления пакетов:
  • Linux kernel 5.10.83
  • Glibc 2.32
  • Systemd 247.10
  • Python3 3.10.0
  • Openjdk : 11.0.9
  • Openssl : 3.0.0
  • Cloud-init: 21.4

Скачать Photon OS 4.0 rev 2 можно в ISO-дистрибутивах для платформ x86_64 и arm64, а также в формате OVA как виртуальный модуль для платформы VMware vSphere. Там же доступны кастомизированные образы Amazon AMI, Google GCE, Azure VHD, а также образ для Raspberry Pi.

Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.

Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.

Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:

Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:

Состав оборудования и особенности тестирования:

• 8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
• Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
• CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
• OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
• OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.

Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.

Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):

Визуализация результатов при изменении числа узлов:

В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:

В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:

Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.

Мы много писали о решении VMware Cloud Disaster Recovery, которое позволяет обеспечивать катастрофоустойчивость виртуальных инфраструктур за счет резервирования онпремизных ресурсов в облаке. Службы VMware Cloud Disaster Recovery позволяют производить восстановление после сбоев по запросу (On-Demand Disaster Recovery) напрямую в облаке VMware Cloud on AWS.

VMware Cloud Disaster Recovery обеспечивает оркестрацию процесса создания реплик на хранилищах S3 Cloud, а также реализацию процесса восстановления инфраструктуры на стороне VMware Cloud on AWS с сохранением показателя RPO равного 30 минутам.

У многих пользователей такой схемы возникает вопрос - а за что они отвечают в этом процессе, за что отвечает VMware, а за что - Amazon?

Ответ можно найти вот тут, мы расскажем об этом вкратце. Итак, VMware Cloud Disaster Recovery состоит из трех компонентов:

• Файловая система Scale-out Cloud File System (SCFS)
• Оркестратор (Orchestrator)
• Коннекторы DRaaS Connectors

VMware запустила свое DRaaS решение в октябре 2020 года и с тех пор предоставляет круглосуточную поддержку этих компонентов, включая накатывание патчей и обновлений на них.

С точки зрения безопасности и операций, ответственность распределяется по трем основным уровням - пользователь, VMware и Amazon AWS:

Пользователь отвечает за:

"Security in the Cloud":

• Безопасность в облаке при развертывании и поддержке окружений VMware Cloud Disaster Recovery
• Безопасность собственной виртуальной инфраструктуры и установку компонентов решения, необходимых для функционирования инфраструктуры катастрофоустойчивости. Также это включает в себя поддержку достаточной скорости соединения между площадками. Пользователь должен заботиться о протоколах шифрования, своевременном обновлении ПО, аудите систем, изменении паролей и всем прочем, что от него зависит.

VMware отвечает за:

"Security of the Cloud" - то есть за безопасность самого облака, что означает защиту систем и программного обеспечения, составляющего основу облака для служб VMware Cloud Disaster Recovery. Очевидно, что это включает в себя не только DRaaS-cервисы, но и платформенные составляющие, такие как VMware vSphere и vSAN.

Amazon отвечает за:

"Security of the Infrastructure" - физические серверы, доступ к ним в датацентрах, функционирование аппаратного обеспечения, исправность физических линий связи и соединений в рамках ЦОД.

Если говорить о разделении зон ответственности в плане конкретных операций и функциональности, то таблица в разрезе указанных трех сущностей выглядит так:

Более детальная информация обо всем этом приведена в документе "VMware Cloud Disaster Recovery Service Description".

В конце лета прошлого года мы писали об интереснейшем документе "VMware vSphere Snapshots: Performance and Best Practices", который содержит весьма полезную многим администраторам информацию о производительности снапшотов, а также лучшие практики по обращению с ними. Мы, кстати, часто пишем про это (1, 2, 3), и хорошо, что теперь об этом есть и подробный документ с картинками.

В конце года VMware решила обновить этот whitepaper, добавив туда немного информации о производительности снапшотов в инфраструктуре контейнеризованных приложений Kubernetes на платформе vSphere.

Тестовая конфигурация там выглядела вот так:

Соответственно, процедура тестирования выглядела так:

• Снимаем базовый уровень производительности для ВМ worker-ноды без снапшотов под нагрузкой
• Создаем снапшот ВМ worker-ноды
• Запускаем бенчмарк и получаем данные о производительности
• Увеличиваем по одному число снапшотов и повторяем цикл тестирования

Тестировались приложения Weathervane и Redis. Результаты показали, что даже при большом количестве снапшотов производительность не падает:

Больше подробностей вы можете узнать в обновленном документе "VMware vSphere Snapshots: Performance and Best Practices".

Продолжаем вам рассказывать о решении NAKIVO Backup & Replication, предназначенном для резервного копирования и репликации виртуальных машин в инфраструктуре VMware vSphere и Microsoft Hyper-V. В прошлой статье мы рассказывали о выходе новой версии продукта, где появились функции мониторинга виртуальных сред, а сегодня поговорим о лучших практиках его использования.

Дункан написал хорошую разъясняющую статью про загрузку ESXi с SD-карты и размещение раздела OSDATA на хранилище в SAN. Напомним, что мы писали о том, что VMware уходит от механизма загрузки ESXi с SD-карт ввиду их низкой надежности и неприспособленности под задачи гипервизора.

Как знают администраторы VMware vSphere, начиная с седьмой версии платформы, структура разделов ESXi теперь выглядит следующим образом:

Как мы видим, все основные разделы, не относящиеся к загрузке переехали в раздел ESX-OSDATA. Многие администраторы хотели бы хранить загрузочный раздел локально на SD-карте, а OSDATA - в сети SAN.

К сожалению, это не поддерживается.

Давайте взглянем на таблицу допустимых конфигураций из вот этой статьи VMware:

Действительно, тут как бы есть пункт, что при загрузке ESXi можно использовать SD-карту для Bootbank, а Managed FCoE/iSCSI LUN для OSDATA (но обратите внимание, что это Locally attached devices). Реально же FCoE, iSCSI и FC для загрузки ESXi с SAN можно использовать только тогда, когда и OSDATA, и Bootbank находятся на SAN-устройстве.

Недавно мы писали об уязвимости Log4j, затрагивающей компоненты веб-серверов Apache Software Foundation log4j Java logging, а значит присутствующей и во многих продуктах VMware. Также мы рассказывали о том, как понять, что вас сканируют на уязвимость log4j, если у вас есть VMware vRealize Network Insight.

Надо сказать, что у партнеров VMware есть такое средство, как HealthAnalyzer, которое осуществляет сбор данных с различных компонентов виртуальной среды и составляет отчет об их состоянии. Оно позволяет собрать детальную информацию о продуктах VMware Horizon, VMware vSphere и VMware NSX, которая включает в себя различные конфигурации и данные об использовании. Собранные с помощью VMware HealthAnalyzer Collector данные можно отправить партнерам VMware или в саму VMware для дальнейшего анализа.

HealthAnalyzer позволит вам обнаружить угрозы, которые описаны в статьях CVE-2021-4428, CVE-2021-45046 и CVE-2021-45105 (а это 10/10 и 7.5/10 по шкале серьезности). Однако чтобы это работало, вам нужно удалить старую версию VMware HealthAnalyzer и поставить новую с портала Partner Connect.

Чтобы удалить старую Java-версию HealthAnalyzer, нужно просто удалить ее папки и связанные файлы. Для виртуальных модулей - нужно выключить ВМ и удалить ее из инвентори.

Также если вы будете использовать предыдущую версию анализатора, то ваши регистрационные данные в форме не будут приняты:

За установкой продукта HealthAnalyzer обращайтесь к своему поставщику VMware.

Ну и бонус-видео о том, как временно обезопасить свой VMware vCenter от Log4j, пока критические фиксы еще в пути:

Компания VMware анонсировала новую версию продукта VMware HCX 4.3, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о возможностях версии 4.2 этого продукта мы писали вот тут.

Давайте посмотрим на новые возможности HCX 4.3:

1. Переход на PostgreSQL

Теперь HCX использует БД PostgreSQL вместо устаревших баз данных, использовавшихся ранее. Для пользователя переход произойдет незаметно, а сами данные в фоновом режиме будут перенесены на новую платформу.

2. Улучшения HCX Network Extension

Теперь для виртуальных модулей Network Extension появились функции высокой доступности (high availability). Так как сервис Network Extension является критичной частью HCX, нарушения в работе которого могут привести к серьезным проблемам с функционированием, то теперь на уровне виртуальных модулей (Virtual Appliance) есть функции HA, которые работают в режиме active/standby. В случае сбоя переключение на запасной узел происходит автоматически.

Диаграмма ниже показывает, как работают виртуальные модули NE, которые формируют пары на каждой из площадок, а во время нормальных операций трафик использует active-туннель между модулями. Другой туннель между standby-модулями также поддерживается, но трафик по нему не идет. На него происходит переключение в случае сбоя основного канала.

HA group 1 и HA group 2 имеют независимые механизмы хартбитов, чтобы мониторить состояние виртуальных модулей.

3. Улучшения OS Assisted-миграций

OS Assisted Migration (OSAM) - это режим миграции виртуальных машин из не-vSphere окружений, таких как KVM и Hyper-V, на платформу vSphere. Здесь было сделано несколько важных улучшений:

• Поддержка новых гостевых ОС - теперь HCX поддерживает миграцию ВМ на базе RHEL 8.x (64-bit) и CentOS 8.x (64-bit) в окружениях KVM на vSphere. Кроме того, можно мигрировать RHEL 8.x (BIOS/GEN-1 & UEFI/GEN-2) и CentOS 8.x (BIOS/GEN-1 & UEFI/GEN-2) из виртуальных машин Hyper-V.
• Совместимость HCX OSAM для vSphere и Cloud Director - теперь при миграции поддерживается связка продуктов VMware vSphere 7.0 U3 и VMware Cloud Director 7.0 U3. 

4. Улучшения юзабилити

• Устранен лимит на 15 символов для имен хостов ВМ на базе MS Windows при кастомизации гостевой ОС.
• Возможность изменять Compute Profile в режиме OSAM. Ранее надо было явно указывать целевой датастор в профиле, теперь же HCX обнаруживает набор датасторов, которые доступны для репликации в кластер. Также происходит валидация, что Sentinel Data Receiver (SDR) имеет доступ к датастору, указанному пользователем.

Более подробно о продукте VMware HCX 4.3 можно почитать на этой странице.

Мы много пишем про растянутые кластеры VMware vSAN Stretched Clusters для онпремизной инфраструктуры VMware vSphere, но не особо затрагивали тему растянутых кластеров в публичных облаках. В частности, в инфраструктуре VMware Cloud on AWS можно создавать такие кластеры, работающие на уровне зон доступности (Availability Zones).

Облачные администраторы знают, что публичное облако AWS разделено на регионы (Regions), в рамках которых есть зоны доступности (Availability Zones, AZ), представляющие собой домены отказа (аналогичные таковым в vSAN). То есть если произойдет сбой (что довольно маловероятно), он затронет сервисы только одной зоны доступности, остальные AZ этого региона продолжат нормально функционировать.

Сама Amazon рекомендует дублировать критичные сервисы на уровне разных зон доступности, а с помощью растянутых кластеров VMware vSAN можно сделать полноценную задублированную среду на уровне AZ в рамках одного региона с компонентом Witness для защиты от ситуации Split-brain, когда будет разорвана коммуникация между зонами:

Для такой конфигурации вам потребуется создать SDDC с поддержкой Stretched Cluster, который создается на этапе настройки SDDC на платформе VMC on AWS. Надо понимать, что при развертывании SDDC можно задать тип кластера Standard или Stretched, который уже нельзя будет поменять в дальнейшем.

Пользователь задает AWS Region, тип хоста, имя SDDC и число хостов, которые он хочет развернуть. Далее администратор выбирает аккаунт AWS и настраивает VPC-подсеть, привязывая ее к логической сети для рабочих нагрузок в аккаунте. Нужно выбрать 2 подсети для обслуживания двух зон доступности. Первая устанавливается для preferred-площадки vSAN, а вторая помечается как сеть для "non-preferred" сайта.

После создания кластера, когда вы зайдете в инстанс Multi-AZ SDDC vCenter вы увидите растянутый кластер vSAN с одинаковым числом узлов на каждой из AZ и один компонент Witness, находящийся за пределами данных AZ.

Такая конфигурация работает как Active-Active, то есть вы можете помещать производственные виртуальные машины в каждую из зон, но вам нельзя будет использовать более 50% дисковой емкости для каждой из облачных площадок.

Конечно же, нужно позаботиться и о защите виртуальных машин как на уровне площадки, так и на уровне растянутого кластера. Лучше всего использовать политику хранения "Dual site mirroring (stretched cluster)" на уровне ВМ. В этом случае при сбое виртуальной машины в рамках одной зоны доступности она будет автоматически перезапущена в другой AZ с помощью механизма VMware HA.

Также администратору надо контролировать физическое размещение виртуальных машин по площадкам, а также политику Failures to tolerate (FTT):

Конечно же, не все виртуальные машины нужно реплицировать между площадками - иначе вы просто разоритесь на оплату сервисов VMConAWS. Администратор должен выставить правила site affinity rules, которые определяют, какие машины будут реплицироваться, а какие нет. Делается это с помощью движка политик storage policy-based management (SPBM) для ВМ и их VMDK-дисков: 

Также более подробно обо всем этом вы можете почитать в статьях vSAN Stretched Cluster Guide и VMware Cloud on AWS: Stretched Clusters.

В конце ноября мы писали о том, что "уже 5 дней VMware находится в состоянии экстренной починки VMware vSphere 7 Update 3", но ситуация оказалась гораздо хуже. Никаких новостей об исправлениях для новой версии, по-прежнему, нет. Напомним, что о новых возможностях vSphere 7 U3 мы писали тут.

Основная информация о возникшей ситуации с последним пакетом обновлений приведена в KB 86398. Там можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281. На странице загрузки VMware vSphere, по-прежнему, висит красный баннер и релиз Update 2a от апреля этого года:

Среди найденных багов - и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и многое другое, судя по заметкам в некоторых блогах:

Если мы зайдем на статью базы знаний "Build numbers and versions of VMware ESXi/ESX (2143832)", то увидим, что последние три релиза vSphere просто зачеркнуты в таблице:

18 ноября зачеркнутые в таблице релизы были удалены из VMware Customer Connect, а новостей по поводу сроков исправления проблем с этого времени не было. Сама VMware пишет в KB вот так:

Надо отметить, что VMware vCenter 7 Update 3 и Update 3a сейчас доступны для скачивания и использования в производственной среде.

В самом интересном положении оказались пользователи, которые уже прошли процедуру апгрейда своей инфраструктуры на Update 3. Им не рекомендуют откатывать все назад (это и не так просто, к тому же), если они не сталкиваются с критичными проблемами, такими как PSOD. Однако и сроков по доступности исправлений Update 3 тоже не дают.

Ждем исправлений!

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

Надо понимать, что конфигурация виртуальной среды в целях обеспечения повышенной (относительно дефолтной) безопасности - это всегда компромисс между защищенностью и удобством использования (как и для любой другой ИТ-системы). Из коробки сама платформа, сервер vCenter и виртуальные машины настроены таким образом, чтобы обеспечить максимальное удобство использования при должном уровне безопасности.

Помните, что изменение настроек безопасности - очень опасная штука, которая требует обязательного документирования и оповещения администраторов об этом. Ведь из-за этого они могут получить проблемы с работой отдельных компонентов, но так и не понять их источника, что будет похуже чисто гипотетической маловероятной атаки, связанной с измененной настройкой.

Сегодня мы посмотрим на 15 действительно полезных рекомендаций и настроек, применение которых не сильно снизит удобство использования, но при этом даст чуть более высокий уровень безопасности, что может оказаться вам в каком-то случае полезным.

Структура списка конфигураций и рекомендаций

Давайте сначала взглянем на колонки Excel-таблицы, которая, по-сути, и является списком настроек и рекомендаций, которые вы можете применить в своей виртуальной инфраструктуре:

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

Итак, давайте посмотрим на 15 самых интересных и, главное, полезных настроек, которые вы можете изменить, а также рекомендаций, которые вы можете выполнять, чтобы повысить безопасность виртуальной среды в своей инфраструктуре.

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.